Method and system for network downloading of music files

ABSTRACT

The invention presents a method for network downloading of music files by obtaining at least one music preference and accessing at least one network based music file, the music file including at least one music attribute. The music attribute is compared to the music preference, and the music file is downloaded based on the comparison.

In general, the invention relates to music collection. Morespecifically, the invention relates to the selection of music fileswithin a network and in particular, to a method for network downloadingof music files as a function of a music player.

Digital cameras, camcorders, digital VCRs such as the Tivo, Internetradios, game consoles such as the X-Box, Internet-enabled refrigerators,and MP3-players are a few of the consumer electronic devices that havebeen influenced by recent Internet and computer technologies. New kindsof applications are possible when the more “traditional” devicefunctionalities (such as playing and recording music and video's) arecombined with Internet enabled services, such as providing informationand e-commerce.

Portable MP3 and other music playing devices have significantlyincreased in their capabilities. Hard drives (internal disk storagedevices) have been installed into music players to allow for the storageof thousands of songs. Additionally, many devices capable of playingmusic files now have the added feature of an Internet connection via awireless modem. This allows the possibility to download songs directlyfrom the Internet to the music (MP3) player. Due to the limited userinterface that these devices have however, make it very impractical togather large numbers of the music files available over network(Internet) connections.

Current Internet enabled personalized music playing devices with harddrive storage have capacities ranging from 1667 songs (5 Gb) to 10000songs (30 Gb). A problem these music players (and the like) have is thatthey rely on the customer (user) to determine how and where to get themusic content from that is to be loaded on his/her music player. Becauseof the limited user interfaces available for the music players, the userhas to enter the exact name and location of each song they wish to betransferred to the player.

Thus, there is a significant need for a method and system fordownloading music files over a network that overcomes the abovedisadvantages and shortcomings, as well as other disadvantages.

One aspect of the invention presents a method for network downloading ofmusic files by obtaining at least one music preference, accessing atleast one network based music file, the music file including at leastone music attribute, comparing the music attribute to the musicpreference, and downloading the music file based on the comparison.

Another aspect of the invention provides a system for networkdownloading of music files. The system includes means for obtaining atleast one music preference, means for accessing at least one networkbased music file, the music file including at least one music attribute,means for comparing the music attribute to the music preference, andmeans for downloading the music file based on the comparison.

Another aspect of the invention provides a computer readable medium forstoring a computer program for network downloading of music files. Thecomputer program is comprised of computer readable code for obtaining atleast one music preference, computer readable code for accessing atleast one network based music file, the music file including at leastone music attribute, computer readable code for comparing the musicattribute to the music preference, and computer readable code fordownloading the music file based on the comparison.

The foregoing and other features and advantages of the invention willbecome further apparent from the following detailed description of thepresently preferred embodiment, read in conjunction with theaccompanying drawings. The detailed description and drawings are merelyillustrative of the invention rather than limiting, the scope of theinvention being defined by the appended claims and equivalents thereof.

FIG. 1 is a schematic diagram for one embodiment of a system foraccessing and downloading music files, in accordance with the currentinvention;

FIGS. 2 a-2 d are illustrations for one embodiment of a graphical userinterface utilizing the system of FIG. 1, in accordance with the currentinvention;

FIG. 3 is a block diagram for one embodiment of a proactive musicgathering method utilizing the system of FIG. 1 and FIGS. 2 a-2 d, inaccordance with the present invention;

FIG. 4 is a block diagram for one embodiment of a flexible reasoningmethod utilizing the system of FIG. 1 and FIGS. 2 a-2 d, and the methodof FIG. 3, in accordance with the current invention;

FIG. 5 is a block diagram for one embodiment of a Profile agentutilizing the system of FIG. 1 and FIGS. 2 a-2 d, and the method of FIG.3 and FIG. 4, in accordance with the current invention;

FIG. 6 is a block diagram for one embodiment of a FreeDB agent utilizingthe system of FIG. 1 and FIGS. 2 a-2 d, and the method of FIG. 3 andFIG. 4, in accordance with the current invention;

FIG. 7 is a block diagram for one embodiment of a Chart agent utilizingthe system of FIG. 1 and FIGS. 2 a-2 d, and the method of FIG. 3 andFIG. 4, in accordance with the current invention; and

FIG. 8 is a block diagram for one embodiment of an OpenNap agentutilizing the system of FIG. 1 and FIGS. 2 a-2 d, and the method of FIG.3 and FIG. 4, in accordance with the current invention.

Illustrated in FIG. 1 is a schematic diagram for one embodiment of asystem 100 capable of accessing and downloading music files, inaccordance with the current invention. The system 100 includes a user110, a music playing device 120, a network connection 130, and a musiccollection 140.

The user 110 is any person who operates the music playing device 120,and may be referred to as user, person, or customer. The music playingdevice (MP3 player, M-player, music player, player) 120 includes MP3players, personal computers, personal digital assistant (PDA), portablecomputers, and hand held communication devices such as an analog ordigital phone, and may have suitable hardware and software fortransmitting and receiving network data communications. In oneembodiment, the music playing device 120 further includes a wirelessmodem for transmitting and receiving data. In one example, the musicplaying device 120 may be an analog mobile telephone operating over aprescribed band nominally at 800 MHz, or the music playing device 120may be a digital mobile telephone operating over a prescribed bandnominally at 800 MHz, 900 MHz, 1900 MHz, or any suitable band capable ofcarrying mobile communications.

In a further embodiment, player 120 contains a speech recognition system(ASR) capable of communicating with the network 130, and contains avoice recognition engine (VRE) capable of word recognition. Anadditional embodiment of the player 120 provides that it is capable offunctioning as any part of, or as all of the above embodiments. Inanother embodiment of the invention, player 120 is capable of datastorage, and/or data retrieval, and/or receiving, processing, andtransmitting data queries. In yet another embodiment, the player 120includes an audio speaker, a synthesized voice output, the audio portionof a television, a display device, an audio channel, or the like.

The network 130 is wireless or fixed and for one embodiment of theinvention includes the Internet. In another embodiment, the network 130is any computer network capable of accessing a network server, fileserver, application server, and/or database server. The music filecollection (music database) 140 is for another embodiment of theinvention a database, and may reside in a database server. In yetanother embodiment of the invention, the music file collection 140 maybe a system capable of accessing or storing a music file, personal audiocollection, or music compact disks (CD's). The music file is of anyformat known in the art suitable for transmission over the network 130and playing on the music playing device 120.

The system 100 is capable of providing methods for a user (customer) 110to obtain songs (music files) from a music database 140, and temporarilyor permanently store the music files on music playing device 120. Onesuch method allows the user 110 to digitalize his or her personal audiocollections (CD's) and put them in a compressed format, such as MP3,onto his or her player 120. Another method provides that the systemutilize a network connection such as the Internet 130 to collect songsfrom a music database 140. Additionally, a method of sharing music filesis quite popular, therefore Internet-based file sharing services areembedded into one embodiment of the music playing device 120. Additionalembodiments of the player 120 have embedded information about theexistence of music-items such as songs and albums, and may include thetype of music the user 110 prefers or requests. A profile of the user110 may be necessary to provide at least one music preference forembodiments of this type. This profile contains information about thepreferences of the user with regard to music aspects (artist, year,label, title), information about the music collection of the user, andthe user's playing behavior. Another embodiment of the player 120 hasthe capability of collecting, reading, and writing meta-data as is knownin the art, about music items. The meta-data may provide the player 120with attributes associated with music files and may include artist,title or release year of a song or album, and the track information ofan album. Another embodiment of the system 100 provides that informationabout network 130 accessible download sites (databases) 140, to beembedded within the player 120.

An embodiment of the invention is illustrated in FIGS. 2 a-2 d,depicting assorted views of a graphical user interface (GUI) for usewith a music gathering application. This embodiment suits the conditionthat a user does not need to know all the details about the events thatare generated by the downloading or playing of music files. When theuser takes a quick look at his or her player, he or she may only want toroughly know how well the music gathering progresses. If the progress isunsatisfactory, the user may want to take actions to resolve theproblem. In the embodiments illustrated as FIGS. 2 a-2 d, the GUI isused to coordinate and summarize the information complexity of musicgathering and downloading.

All four of the illustrations have shared characteristics (overallembodiments) encompassing the shared properties of FIG. 2 a, FIG. 2 b,FIG. 2 c, and FIG. 2 d. The first overall embodiment provides that theinterface (GUI) for a music gathering application is optimized to ascreen size of 240×320, which is a standard size for many players knownin the art. A second overall embodiment provides that the interface issplit into tabs illustrating steps the user may perform in order togather music; the tabs for one embodiment of the invention correspondwith FIG. 2 a, FIG. 2 b, FIG. 2 c, and FIG. 2 d.

A search tab 210 highlighted in FIG. 2 a shows an embodiment a user canuse to aid in the network search for music files. The embodiment of FIG.2 a provides a window (input location) for the user to enter an artistname 215, album 220, or song 225 he or she would like to gather. Theresult of the search is displayed in the form of a hierarchical treestructure 230, ordered by artist, album and song. If the user, forexample, is looking for music of the band “Galaxy 500” then the resultfield will display the albums of this band and within these the songsthat belong to each album. The user may now select, using input devicesknown in the art, any combination of albums and songs that he or shewould like to gather.

A status tab 235 highlighted in FIG. 2 b shows an embodiment for thefeedback or current status of a music gathering action. The numerousaspects of this status, such as the number of available servers, speedof the download and the availability of chart information are toocomplex to be visualized given the small screen size, therefore a comiccharacter face (character) 240 is used for one embodiment of theinvention. The character 240 acts as an emotional interface, providing anatural and instant feedback to the user by means of emotional facialexpressions, to communicate the status of the music gatheringapplication to the user. A simplified OCC emotion model (the emotionmodel of Ortony, Clore, and Collins) as is known in the art, is used tomap the numerous events and actions to emotional states and theirintensities. A subsection chosen from the OCC model focuses on thewell-being type, creating the character 240 expressions that communicatethe internal emotional state of the music gathering application to theworld. The well-being type emotions are mapped to a set of threedifferent emotional expressions: happiness, anger and sadness. In short,all the positive events and actions will result in happiness, all thenegative events will result in sadness and all the negative actions willresult in anger.

The distinction between an event and an action is based onaccountability. It is impossible to blame a person for an Internetconnectivity failure, but if a specific person at a separate networkconnection other than the player cancels the download of the user, thenthe character can be “angry” at that person. The intensity of eachemotional state is based on predetermined variables for one embodimentof the invention.

Four events are identified in this embodiment of the invention that arerelevant for the synthesis of emotions. First, a NewChartInfo event isgenerated whenever a Chart Agent (described below) has obtained new hitchart information from the Internet. New chart information makes thecharacter 240 happy. A second event is the NewGoal event. A MusicCollector Agent (described below) generates this event when it hasdecided to obtain a new song or album. Creating new goals makes thecharacter 240 happy as well. A third event is the NewOpenNapInfo event.It is generated by an OpenNap Agent (described below) when newinformation about OpenNap servers has been found. Because thisinformation increases the likelihood of obtaining songs, the character240 will be happy when this event occurs. Finally, a SearchResult eventis the fourth event in this embodiment of the music gatheringapplication that is relevant for generating emotions. The SearchResultevent is generated by the OpenNap Agent after the OpenNap Agent hassearched for users that share a particular song. When there are userssharing a chosen song the character 240 will be happy; if there are nousers sharing the song or if the song can not be found, the character240 will become sad.

Besides events, actions of agents are relevant for the synthesis ofemotions. The user within this embodiment can perform two kinds ofactions. The user may perform a UserRequest action to instruct the musicgathering application to download a particular song or album, or theuser may perform a CancelUserRequest action to abort downloading aparticular song or album. The character 240 will become happy when theuser requests to download a song or album and it will become angry whenthe user cancels a request, especially when the application has almostcompleted the download. The following table lists the emotionalintensity of the character 240 as invoked by events and associatedvariables. Events (happy & sad) Variables to calculate intensityNewChartInfo Probability of happening, number of new hits. NewGoalProbability of happening, goal type. NewOpenNapInfo Probability ofhappening, number of new OpenNap servers. SearchResult Number ofresults.

The next table lists the emotional intensity of the character 240 asinvoked by actions and their associated variables. Actions (happy &anger) Variables to calculate intensity UserRequest Last time user madea request, type of music item requested. CancelMusicItem The progressstatus of the request. GetAlbumInformation Probability of success,actual success or failure state of the action. ConnectToAnyServerProbability of success, number of failed ConnectToSpecificServeractions. ConnectToSpecificServer Probability of success, last time asuccessful connection was made. DownloadFromAnyuser Probability ofsuccess, number of failed DownloadFromSpecificUser actions.DownloadFromSpecificUser Probability of success, last time a successfuldownload occurred. DownloadedSomeBytes Probability of success.DownloadAbortedByPeer Probability of happening, progress status ofdownload.

A FreeDB Agent (described below) performs the GetAlbumInformation actionwhen the Music Collector Agent requests information about an album. Whenthe action succeeds and information is found about an album, thecharacter 240 will become happy, otherwise the character 240 becomesangry.

One embodiment of the OpenNap Agent performs five actions. AConnectToSpecificServer action is part of a ConnectToAnyServer action.Both actions are used to connect to an OpenNap server. ADownloadSomeBytes action is part of a DownloadFromSpecificUser action,which in itself is part of a DownloadFromAnyUser action. All threeactions are performed when the OpenNap Agent wants to download a song.Finally, a DownloadAbortedByPeer action is any action performed by apeer (user) that stops or prevents the downloading of a file, which theOpenNap Agent has located. This action makes the character 240 angry.

The emotional intensity of the events and actions is calculated by usingrelevant variables that are listed in the above tables. The intensity ofa NewChartInfo event, for example, is based on the probability of thisevent to happen and the number of new hits that has been retrieved. Thecharacter 240 will be happier in cases where the probability of theNewChartEvent is low and the number of new hits is large. The intensityof a CancelMusicItem action is based on the progress of the request. Forexample, the more effort, in terms of download completion, that has beenmade to fulfill the request the angrier the character 240 will be if therequest is canceled. Finally, the ConnectToAnyServer action is composedof several ConnectToSpecificServer actions. In order to connect to aserver the application has to try several specific servers. Theintensity of the character 240 reactions to the ConnectToAnyServeraction depends on how quickly the application can normally connect to aserver (probability of success) and the number of times it had to try aspecific server before it had a connection.

The files tab 250 of FIG. 2 c displays the files that are currently inthe download directory 255 of the application. All songs that the userdownloaded, including the ones being currently processed, are shown in ahierarchy tree. This tree structure allows the user to select anycombination of artist, album and songs and to perform actions on theselection. The user may for example, listen (play) 260 to a song tocheck its correctness and quality or retry 262 downloading songs thathave not been completely downloaded due to an error. Moreover, the usercan delete 264 songs of any artist or album or move 266 them to adatabase such as the music library of a jukebox application.

In the settings (set) tab 270 of FIG. 2 d, the user can adjust thesystem preferences. The proactive music gathering can be switched 280 onan off, the user's music profile can be edited 285 and the desired musicquality for the downloaded songs can be selected from a predefined list275.

An additional embodiment of the invention combines speech technology(voice recognition) with the GUI to improve the usability of the musicgathering application. In this embodiment, the user is able to enter hisor her search query, select actions and check on the status of thegathering by using speech. The screen character provides naturalfeedback of the status of the dialogue by providing conversational andemotional facial expressions.

Additional embodiments of the invention (not shown) include a “gathermore” action or button in which additional music of a particular artistis queried (searched for). Furthermore, the character 240 and GUIfeatures of FIG. 2 a, 2 b, 2 c, and 2 d are customizable, allowing forfeature rearrangement, graphical alteration, and macro programdevelopment.

Another embodiment of the invention generates a good initial userprofile by analyzing the metadata of the user's existing musiccollection. The reliability of the user profile increases as the userscollection of MP3 files increases. Additionally, the character 240 canbecome the personal DJ for the user. Supported by proactively downloadedmusic, the personal DJ generates personalized play lists that the playeror a jukebox application uses to create a radio program simulation forthe user. The personal DJ is context aware and generatesactivity-attuned play lists for birthdays, romantic evenings or parties.In another embodiment, the downloaded content of the music gatheringapplication is not limited to music, but includes the latest stockmarket information, traffic report, and news. The personal DJ also helpsimprove the accuracy of the application's user profile by engaging theuser in a game like setting. In a playful fashion, the applicationreceives feedback on the user's music preferences indirectly ordirectly, by asking questions of the user.

Further embodiments of the GUI include functions (buttons) to play,pause, stop, record, forward and rewind a song. In another embodiment ofthe invention, a “Complete Album” feature assigned as a button orfunction is included as part of the user interface of the audio device(player), similar to the buttons “play”, “stop” or “random play”. Oncepressed, the player will obtain the complete album to which the currentplaying or selected song belongs. These songs may be obtained from theInternet, or from a radio broadcast. In this way, a user can easilylisten to a complete album, upon retrieving one file (music file) ofthat album.

FIG. 3 is a block diagram for one embodiment of a method for proactivemusic gathering 300 and is embedded within the music player, inaccordance with the present invention. This embodiment of the musicgathering application (application) 300 automatically obtains music fromthe Internet based on the user's profile. For one embodiment of theinvention, this may include features, functions, and programming forobtaining at least one music preference, accessing at least one networkbased music file in order to read at least one of the music attributes,and comparing the music attribute to the music preference. The musicfile can then be downloaded over the network based on the comparison.Another embodiment of the invention allows for the user to integratewith the gathering and downloading of music over a network using keystrokes, the graphical interface, or voice commands associated with avoice recognition system.

In order for one embodiment of the music gathering application 300 tofunction properly, four pieces of information are identified that areessential for a proactive music gathering application. First, theapplication 300 should have information about the existence of musicitems such as specific songs and albums. This information is needed inorder to know in general what music items exist and can be downloaded.Second, the application 300 should know what kind of music the userlikes and what specific requests the user may have. Thus, theapplication needs a profile of the user. This profile may containinformation about the preferences of the user with regard to particularmusic aspects. These aspects may include artist name, year of recording,label of distributor, title of song, and title of album. The profile mayalso contain information about the whole music collection within theplayer, and the user's music playing behavior. Third, the application300 should have metadata about the music items it retrieves or stores.For example, the application should have access to metadata for theartist, title or release year of a song or album, as well as for whichtracks and how many tracks are on a particular album. Metadata may beused to determine which music items are liked or disliked by the user.Finally, the fourth information need is about places where to downloadthe music items, e.g. information about download sites on the Internet.

In order for the music gathering application 300 to use the four piecesof information, the information must be formally represented in someway. Therefore, a formal, explicit specification or ontology of a sharedconceptualization is developed. The conceptualization for one embodimentof the invention, refers to a model of the music domain, including thefact that this domain contains concepts such as songs, albums, downloadsite, artist, genre, user preferences, as well as relations betweenthese concepts, such as the fact that songs have certain music aspects(artist, title, genre) and that albums have tracks. The ontologylanguage used was adopted from the DESIRE method, which is an overalldesign method for agent systems that is known in the art.

The architecture for the music gathering application 300, appliesseveral composition principles. First, a differentiation betweennon-agent and agent components is made. The non-agent components of themusic gathering application 300 and its related system architecturereflect traditional components such as collections/databases and media(MP3) playing software components. The agent components reflectcomponents that actively make decisions and whose behavior can beexplained by adopting an intentional stance by attributing beliefs,desires (goals) and intentions to them. A second composition principleapplied in application 300 uses a central agent along with supportagents in the application architecture. The central agent is used forsolving the problem of “what music items to obtain” and sets applicationlevel goals. The support agents provide the central agent with relevantinformation from the Internet and are responsible for addressing theproblem of “how to obtain a particular music item”. Finally, theapplication 300 uses the mirroring of external (Internet) resourcescomposition principle, as is known in the art. Briefly stated, for everyrelevant information source on the Internet, an agent is designed thatincludes the protocols to obtain any required information, and totranslate the information into an internally specified format that isunderstood by the components of the application architecture.

An additional embodiment of the music gathering application notillustrated, structures the application as a single agent. In thisembodiment, one agent is responsible for several tasks, such asgathering information from the Internet, deciding which music items toobtain and downloading files. The single agent application structureconsists of only one main component with a high degree of internalcomplexity to design.

The multi-agent method used by the application 300 provides for the useof modular software components that are incrementally developed anddeployed, and have a higher level of reuse. As mentioned above, themusic gathering application 300 consists of two types of components,non-agent and agent components. The non-agent components include a UserPreference Collection 315 which is a component that contains the user'spreferences about music aspects such as artists, genres, etc; a UserInterface or GUI 310 as described in FIG. 2; an MP3 (or alternativemusic file) Player component that plays MP3 (or alternative music)files; and a Player Collection 370 component which is a component thatcontains all the MP3 (or alternative music) files of the user. Thesecomponents are internally structured using traditional softwareengineering techniques.

The agent components used by the application 300 include a MusicCollector Agent 320, which is a central agent that reasons which musicitems to obtain; an OpenNap Agent 330, which is a support agent thathandles the problem of downloading MP3-files from OpenNap servers on theInternet 380; and a Chart Agent 340, which is a support agent thatmonitors particular Internet sites that contain hit chart information.When new chart information becomes available, the Chart Agent 340 mayalso parse the Internet 380 site and send new information to the MusicCollector Agent 320. Additional agent components used by the application300 include a Profile Agent 350, which is a support agent that generatesa profile of the user based on information about the user's musiccollection, and on the user's playing/listening behavior; and a FreeDBagent 360, which is a support agent that accesses the FreeDB Internet380 site (an open source online database with metadata about albums) toobtain information about the tracks of an album.

The internal architecture of the individual agents is attuned to thefunctions they address and therefore, each agent has a differentinternal architecture. First, the Music Collector Agent 320 has to makeinferences about the music items the user probably likes. The embodimentof the invention illustrated in FIG. 3 adopts a Belief Desire Intention(BDI) architecture that enables the Music Collector agent to make therequired inferences. The BDI architecture is well known within the fieldof agent theory but alternative architectures known in the art may beused.

Second, the OpenNap Agent 330 effectively downloads music files fromOpenNap servers. The OpenNap Agent's 330 architecture is based onreinforcement learning techniques in order to address the problems ofOpenNap servers. These problems include servers and users connecting anddisconnecting from a network in an unpredictable manner, some users notsharing files or having a limit on the number of uploads allowed, andnot every server sharing the same set of files.

Third, the task of the Chart Agent 340 is relatively simple compared tothe former two agents because it only needs to parse Internet sites(html documents) with hit chart information periodically. The ChartAgent 340 has a dedicated architecture for this purpose.

Forth, the Profile Agent's 350 architecture is based on statisticaltechniques to calculate statistics about the Player Collection 370 andthe user's playing behavior.

Finally, the FreeDB Agent 360 has, just like the Chart Agent 340, adedicated architecture that implements the protocol to access an onlineFreeDB music database.

The software components of the music gathering application 300 shouldmeet not only functional requirements but, also a number of more subtlenon-functional requirements. The non-functional requirements include:ease of creation, security, interoperability, integrability,operability, responsiveness, attractiveness, efficiency, expandabilityand stability. The non-functional requirements will be explained belowin detail.

Ease of creation is defined as the degree of effort to create the musicgathering application 300 according to stated requirements.

In general, security is defined as the prevention of unauthorized accessto programs and data. In addition, for the music gathering application300 it is in the interest of the user being the device owner, to keephis personal data and profiles local to the device. In one embodiment ofthe invention, it is a requirement that any information describing theuser is not disclosed to one or more service providers. This requirementhas the effect of ruling out the typical recommended system architecturewhere data of several customers are correlated and easily accessible.

Interoperability for the embodiment of FIG. 3 refers to the ability ofthe application to interact with a number of specified systems, forexample OpenNap and FreeDB servers, to obtain music files and musicmetadata. Not only does the application 300 conform to the pertinentprotocol standards in a formal sense, it also interoperates efficiently,adapting to the timing characteristics of the peers and serversencountered during runtime. The architecture of FIG. 3 supportsinteroperability by the separation of concerns. In one embodiment, forexample, the protocol details and data formatting conventions ofOpenNap, hit charts sites, and FreeDB are each encapsulated in aseparate agent. These agents do not deal with one fixed server or onefixed peer, but dynamically find and evaluate servers and peers on theInternet 380.

Integrability is defined as the degree to which components andembodiments of the application 300 can easily be integrated.Integrability is achieved in one embodiment of the invention by usingshared data structures. Another embodiment achieves integrability byusing dedicated interfaces, based on patterns such as a users listeningpattern.

Operability is defined as enabling the user to operate and control themusic gathering application 300. In one embodiment of the musicgathering application 300, operability must take away most, if not all,of the cognitive load from the user. With regard to this embodiment ofthe invention, the user has no need to program the sequence of musicfragments to be played, to keep track of download statuses, or toremember the IP addresses and other characteristics of peers andservers.

Responsiveness refers to the ability of the application 300 to reactfast enough according to the users expectations and, also, refers to theability of the application 300 to provide sufficient feedback duringprocessing. The application 300 provides a method that reacts fastaccording to the users expectations, because the MP3 Player and theMusic Collector Agent 320 run as parallel threads.

Attractiveness is defined as ‘to be liked by the user’ and for thisembodiment of the invention translates to the functional requirementthat application 300 gathers music items liked by the user, gathersmusic items listed on music rating charts, and takes user feedback andmusic availability into account. With respect to operability andattractiveness, the agents of the application 300 take away most, if notall, of the cognitive load from the user by going to the Internet 380and gathering preferred music without the need for user intervention.

Efficiency is defined as appropriate time behavior and appropriateresource utilization, allowing the music gathering application 300 tooperate with different systems and architectural platforms. Efficiency,for example appropriate time behavior and appropriate resourceutilization, is achieved in one embodiment of the invention by thereal-time aspects of MP3 (or like music format) playing and Internetprotocol handling being provided by separate components, each havingtheir own threads. A problem may be encountered with the handling of alarge number of parallel tasks, each of which can be slow or even canfail, when processed one by one by the Music Collector (collection)Agent 320. An “action execution” mechanism deals with this problem byproviding that parallel work happens outside the application, somewhereon the Internet. In addition, the OpenNap agent 330 is intelligent inthe sense that it learns to stay away from slow and unreliable serversand clients, which of course makes the application more efficient.

Expandability refers to the ease at which the applications functionalityor performance can be increased to meet new needs. Closely related toexpandability, is stability. Stability refers to the minimal effectscaused by the modification of the application 300.

The Music Collector Agent 320 plays a central role in the applicationarchitecture as it sets the application goals. One embodiment of theMusic Collector Agent 320 decides which music items (songs/albums) todownload for the user based on the information it has obtained from theother agents and the user, and based on information from the PreferenceCollection 315 and the MP3 (player) Collection 370 components. Once theMusic Collector Agent 320 has determined which music items to download,it sends a request to the OpenNap Agent 330.

In order for the Music Collector Agent 320 to determine which musicitems to download, it must be capable of analyzing the information ithas received. A flexible reasoning mechanism that is dedicated tooperate within such a practical problem domain as the Internet 380 isessential for the proper functioning of the Music Collector Agent 320.As mentioned above, the BDI architecture may be used for this purpose.The BDI architecture contains three sets of information. First is a setof Beliefs, which contains information about the agent's environment andinternal state. In the application 300, this may include informationabout music items and their aspects, and information about thepreferences and requests of the user, the songs in the MP3 Collectionand specific information about aspects of music items. Second, is a setof Desires that contains information about the objectives or goals ofthe Music Collector Agent 320. In the application 300, the goals mayinclude obtaining music items with a particular music aspect, or mayinclude the desire to have information about the tracks of an album.Third, is a set of Intentions that contains information about theactions an agent will execute in order to realize its desires. In orderto reason and control actions the Music Collector Agent 320 must have aninternal representation of actions. An ontology has been designed forthis purpose such that the agent can reason about the state of theactions it is carrying out. In the BDI architecture, the ‘Actionexecution’ function will update the set of beliefs if the state of anaction changes. In addition, if the set of Intentions contains astatement to control an action, the set of Intentions may be translatedby the ‘Action execution’ function into an actual control of action.

Illustrated in FIG. 4 is a block diagram for one embodiment of aflexible reasoning (BDI) method 400. The upper part of this diagramillustrates ‘Logical Reasoning’ 401, that includes three databasesrepresenting the three sets of information: Beliefs 405, Desires 445,and Intentions 430. Besides the Beliefs 405, Desires 445, and Intentions430 sets, a BDI architecture also contains three functions that operateon these sets. The Generate Options function 440 carries out means-endreasoning and thereby generates new Desires (goals). While doing so, itmaintains consistency between the Beliefs 405, Desires 445, andIntentions 430. For example, if the Music Collector Agent has a beliefthat a particular music item is not downloadable, then it must notcreate a desire to download that song. Another embodiment of thisfunction is to recognize advantageous changes in the environment of theMusic Collector Agent. For example, if the belief that a particularmusic item is not downloadable disappears, it can retry to download thatmusic item.

The Filter function 420 is responsible for three things. First, it dropsintentions that are not achievable. Second, it retains intentions thatcould not be achieved. Third, it adopts new intentions.

The Update function 410 is responsible for updating the set of beliefswith new information. This could be information about the internal stateof the application for example, new preferences or user added musicfiles.

The lower part of FIG. 4 illustrates the ‘Action execution’ 402. Mostlogic based reasoning systems assume that the actions an agent can takeare atomic and consume no time, or at least the time an action takes tocarry out is not taken into account. In this embodiment of thearchitecture, that assumption cannot be made as actions, such asdownloading files and searching the Internet, take time to complete. Itwould be inefficient to wait for each action to be finished, therefore,the implemented BDI architecture provides that actions can be executedand that the agent can reason about the state of an action. An actioncan be compared with a task in a normal computer operating system. Inone embodiment of the invention, an action can be in one of five states,450, 460, 470, 480 and 490. In the IDLE state 450, the action is doingnothing. If an action is created, it will start in this state. Also,when an abort or reset event happens, the action will return to thisstate. In the RUNNING state 460, the action is executing its program oralgorithm for example, a get-info action typically will make aconnection to the Internet to find requested information. In the PAUSEDstate 470, the action is doing nothing. The difference between thePAUSED state 470 and the IDLE state 450 is that the internal state ofthe program or algorithm of the action is saved and restored if theaction is resumed from the PAUSED state 470.

Two states are termination states of the action. In the SUCCEEDED state490, the action has succeeded. In the FAILED state 480, the action hasfailed. The events on which transitions between the states occur aredepicted as 495. The agent has control over the execute, abort, pause,resume and reset events 495. The transitions to the SUCCEEDED 490 andFAILED 480 states are autonomous and depend on the results of the taskimplemented by the action.

The music domain knowledge contained by the three functions, GenerateOptions 440, Filter 420, and Update 410 of the BDI architecture isrepresented in our implementation by rules. A rule consists of anantecedent and a consequent. If the antecedent is true then theconsequent is executed. For example, the Generate Options 440 functioncontains, among others, the following rules: % Rule #1 : download userrequests IF request-obtain-music-item(I:MUSIC ITEM) THENselected-goal(obtain-music-item(I:MUSIC ITEM)) % Rule #2 : alwaysdownload music with aspects the user loves IF preference(A:MUSIC ASPECT,love it) THEN selected-goal(acquire-music(A:MUSIC ASPECT))

The first rule states that if the Music Collector Agent has the beliefthat the user has requested to download a particular music item, then itmust set a desire to obtain that music item. The second rule states thatif the user loves music with a particular aspect (such as music from‘Madonna’) then it sets a desire to acquire music items with thataspect. An example of a rule from the Filter 420 function is: % Rule # :get information about the tracks of an album to download IFselected-goal(obtain-music-item(A:ALBUM)) AND NOTnumber-of-tracks(A:ALBUM, N:NUMBER) AND NOTis-running(get-album-info(A:ALBUM)) AND NOTis-paused(get-album-info(A:ALBUM)) AND NOTis-succeeded(get-album-info(A:ALBUM)) AND NOTis-failed(get-album-info(A:ALBUM)) AND NOTnot-available-album-info(A:ALBUM) THENto-be-executed(get-album-info(A:ALBUM)) Finally, an example rule fromthe Update Beliefs function is: % Rule # : handle result of failedget-album action IF is-failed(get-album-info(A:ALBUM)) THENnot-available-album-info(A:ALBUM) AND NOTto-be-executed(get-album-info(A:ALBUM)) AND NOTis-failed(get-album-info(A:ALBUM)) AND NOTselected-goal(obtain-music-item(A:ALBUM))

Another embodiment of the invention is illustrated as a block diagramfor a Profile agent 500, as shown in FIG. 5. In order to decide whichmusic items to download, information about the user's music interests isneeded. Two types of information are used for this embodiment,preferences and a profile. Preferences are set directly by users. Forinstance, a user can enter that he or she likes a particular genre andhates a particular artist. In the music domain ontology, this can beexpressed by statements such as preference (artist “artist X”, ratingHATE IT) or preference (genre “rock”, rating LIKE IT). A profile on theother hand, is information about the user's music interests that isderived automatically, by observing the user.

The Profile Agent 500 has the responsibility to calculate the user'sprofile. FIG. 5 illustrates the internal architecture of this agent. TheProfile Agent 500 uses two sources to calculate the user's profile. Thefirst source is the music (MP3) Player 528. This source is used to makean estimate (statistical analysis) 520 of the user's playing/listeningbehavior. The second source is the music (MP3) Collection 538. Thissource is used to estimate 520 the user's more static interests, inparticular music aspects. The embodiment provides that from theinformation of which files a user is playing, an indication can beformed of the user's short term interests, and from the music collectionan indication can be made about the user's long term interests, inparticular music aspects. Sensors (as are well known in the art withagents) are used to sense the MP3 player 530 and MP3 collection 540.These sensors receive events when, for example, a user pressed the playbutton, or when a file is added or removed from he MP3 collection. Alistening profile can be calculated 520 using the event that the playbutton has been pressed. If this event happens, the MP3-player sensor530 receives information about the MP3 file that is being played 528.From the ID3 tag of this file, information about the artist, genre,album, etc. can be derived. For each of these music aspects, a frequencyof how often music items with this aspect have been played is calculatedby the equation:Error! Objects cannot be created from editing field codes.  (1)

where N is the number of music items that has music aspect A that hasbeen played over the past T time period. This numerical frequency istranslated into one of the linguistic values NEVER, RARELY, SOMETIMES,OFTEN or ALWAYS. This is done by using threshold values. The followingfrequency intervals are defined. Value interval NEVER fa < once every 2months RARELY once every 2 months ≦ fa < once every month SOMETIMES onceevery month ≦ fa < once every week OFTEN once every week ≦ fa < onceevery day ALWAYS fa ≧ once every day

A collection profile is calculate 520 by using the events when a MP3file is added or removed from the MP3 Collection. The MP3 CollectionSensor 540 is used to detect these events and receives information aboutthe MP3 file 538 that is being added or removed. Again, from the ID3 tagof the MP3 file information about the artist, title, genre, album etc.can be derived. In order to calculate 520 the collection profile foreach music aspect, the number of music items that have this aspect iscalculated. This number is denoted by na, where a is the particularmusic aspect. Finally, this numerical number is translated into one ofthe linguistic values (amount) NONE, SOME, SEVERAL, MANY or A LOT. Thisis done by using threshold values. The following amount intervals aredefined. value interval NONE na = 0 SOME 0 ≦ na < 5 SEVERAL 5 ≦ na < 10MANY 10 ≦ na < 15 A LOT na ≧ 15

The Profile Agent 500 is reactive, meaning it calculates the profileonly if it receives events from the MP3 player or the MP3 collection. Ifthe profile changes then the profile agent 500 will send the new profilethrough the communication mode 510 to the Music Collector Agent.

FIG. 6 is a block diagram of one embodiment of a FreeDB agent 600. Inorder to decide which music items to download, information is neededregarding the music aspects of these items. For example, aspects of aparticular song must be known such as the artist and title of the song,or its genre or release date. This kind of information is called metainformation. Much meta information is included in MP3 files and iscalled the ID3 tag of a MP3 file. The first version, ID3v1, had alimited set of fixed-sized field that included the title, artist, year,genre and comment field. Later versions of the ID3 tag solve the problemof fixed-sized fields and allow for various other types of fields.

Although the ID3 tag of MP3 files is a source of information about musicaspects of songs, it is not enough to download an album. In order todownload an album, knowing what tracks are on it is also required. Thisinformation is found in a database on the Internet 640. One suchdatabase, the CDDB Internet Service, contains album information, such asinformation about the tracks on the album. The CDDB Internet Service isoften used by media players on personal computers. In practice, when auser puts an audio CD in his or her CD-Rom drive, the media playercalculates a (nearly) unique disc identification (ID) that is used as akey to find the album information at the CDDB. Once found, the mediaplayer can display track information (artist, title) relating to theaudio CD. However, due to changes in the license required for accessingCDDB, an alternative database has been developed called the FreeDB.FreeDB is an open-source, CDDB-like database that contains albuminformation.

The FreeDB Agent 600 is an agent that handles the requests to getinformation about songs and albums. FIG. 6 illustrated its internalarchitecture. In one embodiment, a communication module 610 receivesrequests from the Music Collector Agent 605 to find some information.The requests received are typically in the form of get-info(A:ALBUM).The communication module 610 implements the communication protocolsbetween the FreeDB Agent 600 and the Music Collector Agent 605.

Album information can be found at the FreeDB site by constructing aproper URL that contains the request for information about a particularalbum. The communication module translates the get-info(A:ALBUM)statement into a URL and sends it to a URL Sensor 630.

The URL sensor 630 makes a socket connection to the Internet 640 anddownloads the html text indicated by the URL. The html text is sent to aFreeDB html parser 620. This module parses the text, extracts the albuminformation and puts the information into some internally defined datastructure. This data structure is sent to the communication module 610.Finally, the communication module 610 translates the data structure intostatements in our music domain language. Typical statements are in theformat: number-of-tracks(A:ALBUM, N:NUMBER) and is-track(A:ALBUM,S:SONG, N:NUMBER).

The FreeDB Agent's 600 architecture is a reactive architecture. Theagent only undertakes actions if it receives a request and no specialreasoning is needed. When the problem of finding information becomesharder, for example, if different sources are available and each havetheir own properties such as availability, reliability, or quality,reasoning might be needed. In this situation a more deliberativearchitecture is required.

In FIG. 7, a block diagram for one embodiment of a Chart agent 700 isillustrated. The Chart agent 700 provides hit chart information that isuseful for the Music Collector Agent 705 to decide which music items todownload. Hit charts are a source of information about music items thatexist. In particular, they are a source of any new music item thatexists. A hit chart provides the artist name and song title. The ChartAgent 700 has the responsibility of getting a top hit chart each weekfrom the Internet 745. FIG. 7 illustrates the internal architecture forone embodiment of the Chart Agent 700. The Scheduler module 750 triggersthe URL Sensor 740 each week to get a ‘musics top hits’ list from theInternet 745. The URL sensor 740 then sends the received html text tothe ‘musics top hits’ (TOP 50) html parser 730. This component parsesthe text in order to get the necessary hit chart information. The TOP 50html parser 730 sends the text to a chart collection 720 data structure.Finally, the chart collection 720 data structure sends the hit chartinformation as an internally structures data object to the communicationmodule 710. This module sends the information to the Music CollectorAgent 705. The content of the messages are typically in the format:is-hit(S:SONG), has-aspect(S:SONG, M:MUSIC ASPECT).

The Chart Agent 700 is a proactive agent. Every week it checks Internetsites to get new hit chart information.

FIG. 8 is a block diagram for one embodiment of an OpenNap agent 800.The OpenNap Agent 800 is responsible for downloading the requested musicfiles. The OpenNap protocol used is an extension of the Napsterprotocol. With the Napster protocol, all files reside on the clientside. A central server is used to search for files and to initiate thetransfer of files. OpenNap servers can be characterized as a highlyuncertain, dynamic and non-episodic agent environment. A connection toan OpenNap server is made by using sockets. However, it is unpredictablewhether a particular OpenNap server will be up or down at a particularmoment. Once a socket connection has been made, the OpenNap Agent 800has to log into the OpenNap server. Not all OpenNap servers alloweverybody to log in (private OpenNap servers) and most servers have setrestrictions (e.g. the number of connected users is usually limited tosome maximum and every user must share a particular amount of files). Ifa client has logged in, it can start searching for files. The results ofa search request depend on the content being shared by others. Searchqueries return lists of clients who share particular files and theselists may be empty. If a list is not empty, the client can requestanother client to start a file transfer. File transfers may also havedifficulties. For example, most clients place a restriction on thenumber of uploads they serve, which causes any user or application pastthe allotted number that is attempting an upload to be rejected. Inaddition, when both clients are behind a firewall a file transfer cannotbe initiated.

In order to make rational decisions about what to do in the OpenNapenvironment, the OpenNap agent 800 has to maintain a model of theOpenNap environment. This model should contain an up-to-date list of IPaddresses of online OpenNap servers, a profile of every OpenNap serverdescribing the last time when logging in failed and a quality measurecomposed of the number of successful logins, the number of successfulfile downloads from this server, a profile of every client describingthe last time when a download failed, and an estimation of theprobability of a successful download.

FIG. 8 illustrates the internal architecture of the OpenNap Agent 800.The Communication module 810 receives requests from the Music CollectorAgent 805 to download particular files. The Communication module 810sends information to the Planner module 820. The Planner module 820decides what action to take. The actions the Planner module 820 canchoose from include download an up-to-date OpenNap server list, connectto a server, search for a file, download a file, or close a serverconnection.

When the Planner module 820 decides to download an up-to-date OpenNapserver list from the Internet, it sends a trigger signal to the URLSensor 870. Subsequently, the URL sensor 870 starts downloading an htmldocument from a website 865, for example the Zeropaid.com web site,containing information about online OpenNap servers. This document issent to the OpenNap Server List Parser 860 that parses the html documentin order to get the server information. All server information is putinto a data object that is sent to the planner 820.

The Planner module 820 may choose, as an action, to download a MP3 file.Before a music file can be downloaded, a connection to some OpenNapserver must be established. Therefore, the Planner module 820 sends aconnection request to the OpenNap Client module 830, together with anaddress of a particular server whose address was obtained previouslyfrom the Internet. The OpenNap Client module 830 implements the actualOpenNap protocol over the Internet 832. If the connection fails, theOpenNap Client module 830 sends a message to the Planner module 820. ThePlanner module 820 may decide to reconnect or to try another OpenNapserver.

The procedure to download a music (MP3) file from an OpenNap serverstarts with a search action. The Planner module 820 sends a request tothe OpenNap Client module 830 to search the OpenNap server for aparticular file. When the OpenNap Client 830 issues a search request onthe OpenNap server, it will receive a list of clients sharing that file.This list is passed on to the Planner module 820 that decides from whichclient to download the file. It often occurs that a download request isnot accepted. The Planner module 820 then decides to download the filefrom another client. Another embodiment of the invention may providethat after a specific download time has been surpassed, or if a specificnumber of clients do not accept the request, the request fails and thePlanner module 820 disconnects from all open connections. Once all filesare downloaded the Planner module 820 requests to close the connection.

The received files are added to the MP3 Collection 834 by the OpenNapClient Module 830. By default, the MP3 Collection 834 sends an event toall listeners when a file is added or removed so that the MusicCollection Agent 805 will be notified that there is a new file in thecollection. The Planner 820 sends back a notify message to the MusicCollector Agent 805 each time a download request of a particular MP3file has been successful or has failed.

Another embodiment of the OpenNap agent 800 provides that the OpenNapagent 800 learns the quality of clients and servers by usingreinforcement learning techniques as are known in the art. In oneembodiment of the reinforcement learning technique, the quality (Q)values of servers or users are denoted by Q(server) and Q(client)respectively. These quality values are calculated from ‘rewards’ thatare received while trying to download requested files. Rewards arepoints appointed for each time a logon to a music file server issuccessful. The quality value of servers is calculated from rewardsreceived after an attempt to login, and after a download session fromthat server. The user's values are calculated rewards received after anattempt to download a file from that user.

A fragment of the Planner's 820 algorithm to connect and disconnect froman OpenNap server is listed below. The strategy to pick a server is thec-greedy method as is known in the art. Only for a small amount oftrials (c %), is a random server selected. During the other trials, thebest server is selected; that is, the server with the highest Q value isselected. Algorithm lines 5-10 implement this strategy. A protection toavoid subsequent trials of unsuccessful server logins has been built in.If a login action fails, then the time of this event is remembered. Onlyafter a certain amount of time can a server be selected again.

Updating the Q value of servers is done in lines 15-21 for loginrewards.  1: repeat  2: % update OpenNap server list  3:ServerList.update( )  4:  5: % select an OpenNap Server using ε-greedymethod [21]  6: if RandomGenerator.getNumber( ) < ε1 then  7: server

ServerList.getRandomServer( )  8: else  9: server

ServerList.getBestServer(tretry_timeout) 10: end if 11: 12: % try tologin 13: server.login( ) 14: 15: % update Q(server) by login reward 16:if server.isLoggedIn( ) then 17: Q(server)

Q(server) + α1[1 − Q(server)] 18: else 19: Q(server)

Q(server) + α1 [0 − Q(server)] 20: LastTimeFailedLogin(server)

tcurrent 21: end if 22: until server.isLoggedIn( )

The above described methods and systems for network downloading of musicfiles are example methods and systems. These methods and systemsillustrate one possible approach for network downloading of music files.The actual implementation may vary from the method discussed. Moreover,various other improvements and modifications to this invention may occurto those skilled in the art, and those improvements and modificationswill fall within the scope of this invention as set forth below.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive.

1. A method for network downloading of music files comprising: obtainingat least one music preference; accessing at least one network basedmusic file, the music file including at least one music attribute;comparing the music attribute to the music preference; and downloadingthe music file based on the comparison.
 2. The method of claim 1 furthercomprising, viewing a progression of network downloading of music filesas a function of an emotional interface.
 3. The method of claim 1further comprising, downloading a second music file based on the firstmusic file, as a function of a complete album feature.
 4. The method ofclaim 1 further comprising, providing interaction with the networkdownloading of music files as a function of a graphical user interface.5. The method of claim 1 further comprising, providing interaction withthe network downloading of music files as a function of a voice command.6. The method of claim 1 wherein the music preference is selected from agroup consisting of an artist name, year of recording, label ofdistributor, title of song, and title of album.
 7. The method of claim 1wherein the music preference is obtained from a user preferencecollection.
 8. The method of claim 1 wherein comparing the musicattribute to the music preference is a function of a music collectionagent.
 9. The method of claim 1 wherein accessing the network basedmusic file is a function of an agent selected from a group consisting ofa freed agent, a chart agent, and an opennap agent.
 10. The method ofclaim 1 wherein the music file is downloaded to a music playing device.11. A system for network downloading of music files comprising: meansfor obtaining at least one music preference; means for accessing atleast one network based music file, the music file including at leastone music attribute; means for comparing the music attribute to themusic preference; and means for downloading the music file based on thecomparison.
 12. The system of claim 11 further comprising means forviewing a progression of network downloading of music files.
 13. Thesystem of claim 11 further comprising means for downloading a secondmusic file based on the first music file, as a function of a completealbum feature.
 14. The system of claim 11 further comprising means forproviding interaction with the network downloading of music files as afunction of a graphical user interface.
 15. The system of claim 11further comprising means for providing interaction with the networkdownloading of music files as a function of a voice command.
 16. Acomputer readable medium storing a computer program for networkdownloading of music files comprising: computer readable code forobtaining at least one music preference; computer readable code foraccessing at least one network based music file, the music fileincluding at least one music attribute; computer readable code forcomparing the music attribute to the music preference; and computerreadable code for downloading the music file based on the comparison.17. The computer readable medium of claim 16 further comprising computerreadable code for viewing a progression of network downloading of musicfiles as a function of an emotional interface.
 18. The computer readablemedium of claim 16 further comprising computer readable code fordownloading a second music file based on the first music file, as afunction of a complete album feature.
 19. The computer readable mediumof claim 16 further comprising computer readable code for providinginteraction with the network downloading of music files as a function ofa graphical user interface.
 20. The computer readable medium of claim 16further comprising computer readable code for providing interaction withthe network downloading of music files as a function of a voice command.